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ABSTRACT 

A significant part of the call processing software for Lucent's new PathStar™ 
access server [FSW98] was checked with formal verification techniques. The verification 
system we built for this purpose, named FeaVer is accessed via a standard web browser. 
The system maintains a database of feature requirements together with the results of the 
most recently performed verifications. Via the browser the user can invoke new verifica- 
tion runs, which are performed in the background with the help of a logic model checking 
tool. Requirement violations are reported either as high-level message sequence charts or 
as detailed source-level execution traces of the system source. A main strength of the 
system is its capability to detect potential feature interaction problems at an early stage of 
systems design, the type of problem that is difficult to detect with traditional testing tech- 
niques. 

Error reports are typically generated by the system within minutes after a comprehensive 
check is initiated, allowing near interactive probing of feature requirements and quick 
confirmation (or rejection) of the validity of tentative software fixes. 



1. Introduction 

Distributed systems software can be difficult to test The detailed behavior of such a system typically 
depends on subtle timings of events and on the relative speed of execution of concurrent processes. This 
means that errors, once they manifest themselves, can be very hard to reproduce, and it means that when the 
system passes a series of tests, one cannot safely conclude that the same tests can never fail. The situation 
is further complicated when we deal with increasingly complex software with multiple feature packages, a 
phenomenon that most PC users today will be familiar with. The problem also exists in the systems code of 
large telephone switching systems. 

The best-known manifestation of the problem in call-processing applications is the so-called feature inter- 
action problem [KX98]. Telephone companies can compete with elaborate feature packages that are 
offered to customers* ranging from standard features such as call forwarding, to more obscure variations 
like call parking. The number of distinct features offered on a main switch today can be well over one hun- 
dred. Each of these features can require a different response to the same basic set of events that can occur 
on a subscriber line, and thus the feature interaction problem is born. With just 25 features there can 
already be I 25 possible feature combinations. If each combination could be tested in a second, it would 
take about a year to test all combinations. By any standard, this is an undesirable strategy. For a simple 
example of feature interaction, consider what the required response of the switch is if a customer has both 
an anonymous call rejection and a call forwarding feature enabled simultaneously. Which of these two fea- 
tures should take precedence when an anonymous call arrives for this customer? 

Fortunately, in practice the situation is not quite this bad. Telcordia, the former BellCore, has issued stan- 
dards on feature behavior that switch providers must comply with [B92-96]. According to these standards, 
some feature combinations are not allowed, some are non-conflicting, and for some a feature precedence 
relation is prescribed that determines which feature behavior is to take precedence in case of conflict. (For 
the example above, for instance, the rules state that the anonymous call rejection feature should take prece- 
dence.) Unfortunately, the rules from the standards are not always complete, and they are sometimes hard 
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to interpret unambiguously. The task of systematically checking if the Telcordia standards have been 
implemented correctly by a vendor of a switching system therefore remains formidable. 
Methods that can be used to mechanically verify distributed systems software should be of considerable 
value in industrial software design. Specifically, we are interested here in methods that can be used to for- 
mally verify the call processing software, and specifically the feature code, for a new commercial switch. 
We will describe a system named FeaVer, that can accomplish this feaL 

Earlier attempts to apply automated verification techniques to distributed software applications generally 
have relied on hand crafted formal models, often produced by verification experts over a period of months 
in collaboration with the developers of an application, e.g. [CAB98HS981. Because of the time required to 
construct formal models by hand, detailed changes in the source application cannot easily be tracked with- 
out a significant reinvestment of time and energy. By eliminating the need for hand crafted models, the 
system we will describe can be used to verify virtually every version of an application, tracking the evolv- 
ing source throughout the design cycle. 

In the next few sections we will discuss the central components of the FeaVer feature verification system: 

• Mechanized model extraction: a method for mechanically extracting verification models from imple- 
mentation level code, controlled by a user-defined conversion table. 

• Formulating properties: defining the set of formal requirements that the application has to satisfy. In 
our case many properties could be derived from the Telcordia standards for call processing feature 
implementation. Others define more specific local requirements or are more exploratory in nature. 
The use of a database of correctness properties is comparable to the use of test suites and test objec- 
tives in a traditional testing method. 



• Logic model checking: the method that is used to mechanically verify if the system satisfies or possi- 
bly can violate one or more of the stated requirements. 

• System support the mechanics of the verification process, including the use of a system of net- 
worked PCs, called TrailBlazer, to execute verification jobs in parallel. 

We conclude the paper with a summary of our findings. 

2. Mtochanizftd mod*! •xtmction 

It is known that it is not possible to devise an algorithm that could prove arbitrary properties of arbitrary C 
or C++ programs. It is not even possible to mechanically prove a single specific, property such as program 
termination for arbitrary programs [T36][S65]. So if we want to be able to render proofs, we have no 
choice but to restrict ourselves to a smaller class of programs. An example of such a class is the set of all 
finite state programs: programs that on any given input can generate ooly a finite number of possible pro- 
gram states (i.c memory configurations) when executed. We call a simplified program of this type a 
model. The set of all possible executions for a finite state model defines a finite directed, and possibly 
cyclic! graph- Even without explicitly constructing the complete graph, which can still be large, we can 
now reason about feasible and infeasible paths in the graph, and prove if certain executions are possible or 
not This is precisely what a logic model checker is designed to do. 

The first problem to be solved then is to reduce a given C or C++ program to a meaningful finite state 
model that can be analyzed The reduction will bring a loss of information, so it has to be chosen in such a 
way that relevant information is preserved and irrelevant detail removed. What is 'relevant* and what is not 
depends on the properties that we are interested in proving about the program. If, for instance, the function- 
ing of the billing subsystem is not mentioned in any of the system requirements we check, than all access to 
and manipulation of billing data can be stripped from the program to produce the model. Some care has to 
be taken, though, to guarantee that the removal of code preserves our ability to find all property violations. 
The following procedure will ensure this. 

All assignments and function calls that have been tagged as irrelevant to the verification effort are replaced 
with a skip (a dummy no-op in the modeling language). All conditional choices that refer to data objects 
tagged as irrelevant are replaced by nondetenmnistic choices. The use of nondeterminism is a standard 
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reduction technique that can be used to make a model more general, broadening its scope. The nondeter- 
minism tells the model checker that all possible outcomes of a choice should be considered equally possi- 
ble, not just one specifically computed choice. The original computation of the system is preserved as one 
of the possible abstracted computations, and the scope of the verification is therefore not restricted. If no 
property violation exists in the reduced system, we can safely conclude thai no property violation can exist 
in the original application 

The reduction method is Tail-safe* in the sense that if we chose the reduction incorrectly, the above result 
still holds true, although the reverse does not [AL91],[CGL94],[K95],[B99]. It is possible, for instance, that 
the full expansion of an error trace for a property violation detected in the reduced system does not corre- 
spond to a valid execution of the original application. If this happens it constitutes a proof that information 
was inadvertently stripped from the system that was in fact relevant to the verification. In this case at least 
one of the conditional choices in the abstract trace will turn out to be invalid in the concrete trace, not 
matching assignments to data objects earlier in the trace. These data objects are now known to be relevant 
to be properties being verified, and the reduction can be adjusted accordingly. Typically a few iterations of 
this type suffice to converge on a stable definition of an abstraction that can be used to extract a verifiable 
model from a program text, as we will discuss in more detail below. 

The PathStar Code 

In the verification of the code for the PathStar access server [FSW981, shown in Figure I, our focus is 
exclusively on the verification of telephony features. Since we are not looking for faults in the sequential 
code of device drivers, process schedulers, memory allocation routines, billing subsystems, etc., the func- 
tion of such code can be abstracted. For device drivers, for instance, it means that the abstractions used do 
not enable us to check that a device driver administers dialtone correctly when given the appropriate com- 
mand by the controller, but it does enable us to check that the controller can only issue the appropriate com- 
mands when required, and cannot fail to do so [HS99]. 
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Fig. 1 — The PathStar™ Access Server 
Providing data and voice service over a variety of media. 
In the PathStar code the function of the controller is specified in a large routine that defines the central state 
machine for all basic call processing and feature behavior. This routine, roughly 1,600 lines of C source, is 
executed concurrently by a varying number of processes, jointly responsible for the handling of incoming 
and outgoing calls. In the extracted model for this code, we carefully preserve all concurrent behavior and 
the complete execution of the state machine, be it in slightly abstracted form. 

Nondetenninistic test drivers in the model are used to generalize the behavior of all parts of the system that 
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are external to tbe state machine: subscriber behavior, connected devices, remote switches. The source text 
of the original program is preserved in the abstract model so that we easily reproduce a concrete trace from 
any abstract error trace that is discovered. 

With the reduction process we have outlined, the control flow of the original source is preserved in the 
reduced model. Data access, however, passes through a user-defined abstraction filter. This filter, defined 
as a conversion lookup table, determines which operations are irrelevant to the properties to be verified 
(e.g., function calls for billing and accounting) and which need to be represented either literally, with an 
equivalent representation in the language of the model checker, or in more abstract form. The irrelevant 
operations are mapped into the null operation of the model checker. 

Th# Conversion Tabto 

From ail different types of statements that appear in the PathStar call processing code, about 60* are 
mapped to an equivalent statement in the extracted model (i.e., they are preserved in the abstraction), cf. 
Figure 2. This includes all statements that cause messages to be sent from one process to another (like call 
requests, call progress and call termination signals), and all statements that are used to record or test the call 
state of a subscriber. 

The remaining statements and conditionals are abstracted in one of three ways, depending on their rele- 
vance to the verification effort 

1. A statement that is entirely outside the scope of the verification is replaced with skip and thereby 
stripped from the model as also discussed above. This applies to about 30% of the cases. 

2. If a statement is partially relevant, the conversion table defines a mapping function that preserves 
only the relevant part and suppresses the rest For example we do not use the absolute values of 
timers in our verifications. For the properties we define it suffices to know only if a timer is running 
or not and therefore the integer range of possible timer values can be reduced with a mapping func- 
tion to tbe boolean values true and false: indicating whether or not a timer might expire. This map- 
ping could not be used if we were to include requirements on the real-time performance of the Path- 
Star switch. Other examples of this type of abstraction are cases where the details of an operation are 
irrelevant, but the possible outcomes are not For instance, digit analysis can be an involved operation 
that is mostly irrelevant to the functional correctness of the call processing code. Only relevant is that 
the controller deals correctly with the possible outcomes of this operation: to respond properly when 
an abbreviated number or a feature access code is recognized, to start routing the call if it is deter- 
mined that sufficient digits were collected, or to wait for the subscriber to provide more digits, with 
the proper timers set to guard the inter-digit timing interval In this case the conversion table replaces 
the operation with a nondeterministic choice of tbe possible outcomes. 

3. The third type of abstraction is used when an operation is fully relevant said needs to be preserved in 
the model, with only syntax adjustments. 



Method 


Percentage of Code 


Fully abstracted (stripped) 

Functional and Non-deterministic abstraction (mapped) 
Not abstracted (preserved) 


30% 
10% 
60% 



Fig. 2 — Ratio of basic types of abstractions applied 
To track changes in tbe source text, and to retain the capability to extract models, we only have to keep the 
conversion table up to date, rather than a fully detailed hand-crafted model. Some changes in the source 
require no update at all. This is the case, for instance, if code is copied or moved without the introduction of 
new types of data manipulation. When a new type of data access appears, the model extractor warns the 
user and prompts for a new entry in tbe conversion table. In most cases the new entry can be defined with- 
out knowing anything about the purpose of tbe change or it's impact on behavior. Typically, a week's 
worth of upgrades of tbe call processing code translates into ten minutes of work on a revision of the con- 
version table before a fully mechanized verification of all properties can be repeated. More detail on the 
definition of conversion tables can be found in [HS99]. 
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Assumptions about the Environment 

The call processing code in PathStar interacts with a number of entities in its environment: subscribers, 
remote switches, database servers, and the like. The task of constructing precisely detailed behavior defini- 
tions for each of these entities would be both formidable and redundant [H97]. 
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Fig, 3 — Verification Context 
The verification context consists of a conversion map that defines the level of 

abstraction, test drivers (hat capture the essential assumptions about the 
environment, and a database of properties that define the system requirements. 
For each remote entity that interacts with the call processing controller it suffices to construct a small 
abstract model that captures a conservative estimate of the possible behaviors of these entities in a general 
way. Note that our objective is not to verify the correct behavior of the remote entities, but that of our own 
switch despite the presence of possibly ill-behaved remote entities. The system requirements, test drivers, 
and the conversion map together define the verification context, as illustrated in Figure 3. 
We can, for instance, define an abstract model for generic subscriber behavior with a simple demon that can 
nondeterministicaily select an action from all the possible actions that a subscriber might take at each point 
in a call: going on- or off-hook, flashing the hoot dialing feature access codes, etc. Similarly we can 
model the possible responses from a remote switch to call requests from the local controller, using a demon 
that can generate possible responses nondeterministicaily. 

Abstractions such as these, based on nondetenninism. achieve two objectives: they remove complexity by 
removing extraneous detail, while at the same time broadening the scope of the verification by representing 
larger classes of possible behavior, instead of selected instances of specific behavior. 

3. Formulating Propsrtiss 

The database for feature verification of the PathStar code that we have constructed contains approximately 
80 properties for 20 features. For each feature set the database further defines one or more provisioning 
constraints. When verifying the correct implementation of any given feature we must, for instance, be able 
to specify that the feature is to be enabled and that incompatible features are to remain disabled. These 
additional constraints could be included in the definitions of the properties themselves, but the extra infor- 
mation would hamper their readability. By decoupling provisioning detail from functional properties we 
can more easily experiment with different types of provisionings on a common set of properties. It is, for 
instance, possible to check the correct implementation of feature precedence relations by deliberately 
enabling and disabling higher precedence features. In the absence of an explicit provisioning constraint, the 
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model checker will assume no knowledge about the enabledness or disabiedness of features, leaving this to 
nondeterministic choice* 

For each feature, each property is verified for each related provisioning constraint For 80 properties this 
translates, in our current database, into approximately 200 separate verification runs. The number of runs 
to be performed for a full verification of the source code can change with the addition or deletion of proper- 
ties or provisioning constraints, - ^ - 

An Example 

As a simple example we will consider the formalization of the requirement that when a non-ringing phone 
is picked up, dial-tone is generated Clearly, there are some exceptions to this rule. When the line is provi- 
sioned as a hodine, with a direct call feature, or when the line is provisioned with the denial of originating 
service feature' then no dialtone will be generated. To check this property, therefore, we need to define a 
provisioning constraint that disables such higher priority features. 

One method to specify this property is to use a simple form of linear temporal logic. Temporal logic, intro- 
duced in the late seventies for the concise formulation of correctness properties of concurrent systems 
[P77], defines a small number of operators that allow us to reason about executions. In temporal logic the 
example property can be specified as follows: 

□ ( offhook ~» X 0 ( dialtone v onhook) ) 

In this case we allow for the possibility that the subscriber returns the phone onhook before actually hearing 
the dialtone, which would of course be valid. The troth value of a temporal formula is evaluated over exe- 
cution sequences. This means that if we evaluate the formula at any given point in a system's execution it 
would return true if and only if the complete remainder of the execution from that point forward satisfies 
the property stated 

Three unary temporal operators are used in the formula above: Q (always), X (next), and 0 (eventually). □ p 
states that p is true now and will remain invariantiy true throughout the rest of the computation. X p states 
that p will be true after the next execution step. 0 p states that p is either true now or it will become true 
within a finite number of future execution steps. The right-arrow, denotes logical implication: (p -» q) 
means hpv q), where -> is logical negation and v is logical or. 

The model checker will use this formula to check if there can be any system executions that would violate 
the property. This procedure works by first negating the formula, so that we get a formalization of a violat- 
ing execution. The negated formula for the example can also be derived manually as follows, using stan- 
dard rewrite rules from boolean and temporal logic: 

( offhook X 0 ( dialtone v onhook) ) * 
0 ( offhook -> X 0 ( dialtone v onhook) ) * 
0 ( -i offhook v X 0 ( dialtone v onhook) ) ■ 
0( offhook a X 0 ( dialtone v onhook) ) « 
0 ( offhook a X -n 0 ( dialtone v onhook) ) ■ 
0 ( offhook a Xo(-> dialtone a onhook) ) 

This negated fonnuia can be converted mechanically [GPVW95] into a 2-state ©-automaton, illustrated in 
Figure 4, which is used in the model checking process. 

Timlin* Editor 

For the specification of complex behavior, e.g., to capture properties on the correct functioning of a six-way 
conference call an accurate formalization of the property in temporal logic can pose a challenge. We have 
therefore experimented with an alternative method for specifying properties using a simple graphical user 
interface. Though this form of property specification is not as general it covers many of the types of prop- 
erties we are interested in. All properties specified in this way can be translated mechanically into temporal 
logic formulae, or also directly into property automata for use in the model checking process. Figure 5 
shows the specification of the earlier property, checking for dialtone after an offhook. 
The timeline editor allows the user to define events that are part of the required behavior on a horizontal 
line. Most events are markers that are used to identify the execution sequences of interest These events 
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Fig. 4 — Property Automaton. 
This (^automaton (side box B) is automatically extracted from a temporal logic formula. It defines 
the set of behaviors that would violate the property, and is used in the verification process much like a 
' pattern. ' to search the set of all possible system executions for matches. 



Fig. 5 — Timeline Editor 
The timeline editor provides an intuitive alternative method for property specification. The user 
defines events and a test target, and mark multiple, possibly overlapping, intervals with constraints. 
are labeled with an e in the diagram. Other events are required to appear in response to the earlier events. 
These required events are marked with an r (not shown in Figure 5). The last event of the sequence is 
always required and is marked with at (for target). The model checker will flag an error if it can construct 
an execution sequence in which the markers (e) are present, but one or more of the required events ( r and t) 
are missing. 

The timeline editor also allows us to state that certain events must be absent for the execution to be of inter- 
est In this cue, this applies to onhook events. These conditions are specified as constraints on the execu- 
tion, using a horizontal bar undtt the timeline to identify the precise part of the execution to which the con- 
straint applies. For events or conditions that are not mentioned as events or in constraints, no restrictions 
apply. 

The property definition shown in Figure 5 is automatically converted into the same automaton as shown in 
Figure 4, so the two methods of specification yield identical checks in this case. 

4. Logic Model Checking 

The formal models extracted from the source of the application are specified in the language of the LTL 
model checker SPIN [H97]. SPIN models define the behavior of systems of asynchronous processes that 
can communicate via message channels, rendezvous ports, or via shared data. SPIN converts the input 
specification into a product of automata. The global behavior defined by this product can be checked effi- 
ciently for a wide range of correctness properties using an automata theoretic model checking procedure 
[VW86]. To perform the check, SPIN starts by computing an automaton that captures all possible viola- 
tions of a given correctness property. If the property is specified as a formula in linear temporal logic 
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Rg. 6 — Overview of tbe Model Checking Process 
[P77], for instance, SPIN lakes the logical negation of tbe formula and converts it into a test automaton 
using tbe procedure defined in [GPVW95]. This automaton formalizes system executions that should not 
be feasible if the application is designed correctly. Next SPIN searches tbe intersection product of the lan- 
guage defined by the negated property automaton and the language defined by the automata that was 
extracted from the system. If the intersection product is empty, no violations of the property are possible 
and the system passes the test If the intersection product is not empty it contains at least one complete exe- 
cution that is both in the lanuage of the system (i.e., it is a possible execution of the system as specified) 
and in the language of the negated property (i.e., it constitutes the violation of a property). In this case 
SPIN will generates that execution sequence as proof that the property can be violated. In the FeaVer sys- 
tem the sequence is converted back into the source language of the application, using a reverse lookup in 
the table that was used to extract the formal model from the source of the application. The verification pro- 
cess is illustrated in Figure 6. 

5. System Support TraiiBlazer 

The main interface to the feature verification system is a standard web-browser. Through the browser the 
user can check on the verification status of all properties, lookup the text and the justification of each prop- 
erty, refer to the source text of tbe Telcordia feature requirement documents, and inspect reported error 
sequences in a number of different formats. An error sequence can be displayed as a message sequence 
chan in either ASCII or graphical form (Figure 7), or it can be displayed as a detailed dump of a series of 
concurrent execution traces interleaved in time, with one trace for each of the processes that participated in 
the failed execution. The detailed execution traces list all concrete C statements and conditions that are 
executed or evaluated during the execution, in time sequence. Typically such a sequence reveals subtle 
race conditions in the interleaving of actions that can lead to faults. 

The main pieces of the infrastructure for tbe checking process: test drivers, the conversion lookup table, and 
the supporting text for properties are created and maintained with a standard text editor. 
The source code of the application is maintained by the developers and parsed directly by the FeaVer soft- 
ware when a verification run is initiated. 

Verification runs are always initiated by the user through the web interface. It would also be possible to 
automatically trigger a comprehensive series of checks each time that the FeaVer system detects that either 
the source of tbe application or tbe text of a property has changed, say in tbe early morning hours of every 
day. So far, however, we have not used this intrigueing possibility. 
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Fig. 7 — A Sample Property Violation 
A sample execution sequence, shown here in graphical form as a message sequence chart, presented 
by the verification system as proof that executions are possible in which dialtone is not generated 
In this case the property violation can occur if the subscriber has call forwarding, and happens to 
pick up the phone precisely when an incoming call is being forwarded In an unlikely scenario, the 
call processing software can be made to delay the generation of dialtone arbitrarily long while the 
system is rejecting or forwarding more incoming calls. When the calls stop, the system will eventually 
timeout and deliver dialtone (not shown hereh The scenario can also be presented as a trace of C 

statement executions. 

To initiate a check the user selects one or more properties and provisioning constraints from tbe web inter- 
face, and initiates the check with the click of a button. The remainder of this section describes what hap- 
pens when the button is pushed. The tasks to be performed in tbe verification process are divided over a 
number of server applications that can nm anywhere in the network. This capability to spread the work 
over several machines allows us to exploit large numbers of independent processors to assist in the execu- 
tion of verification tasks. Tbe additional processors art not necessary for FeaVer to perform its tasks, but, 
they can provide significant speedups. The network of processors that we have assembled for this purpose 
is called TrailBlazer (Figure 9). Four basic types of servers together provide the required functionality 
tbjxep, tb sched, tb_exec, and tbjvrap, as illustrated in Figure 8 and explained in more detail below. 
1. The FeaVer web browser sends a request to initiate one or more verification runs to a server called 

tb_prep. This server receives the property and provisioning information that the user provided and 

starts tbe process. 

It calls a program called pry to parse the C code of tbe application, identify the state routine, and con- 
vert it into an intermediate format, organized as state, event, transition triples. Another program, 
called catch then parses this intermediate format and generates a SPIN verification model using the 
conversion map. Catch adds the user defined test drivers (defining context), suitably translated pro- 
visioning information, and tbe property, after converting it into automata form. On average there are 
two local states in tbe SPIN model for every line of source code in the application. The final model 
defines the behavior of 7 different types of processes (several of which are used to create multiple 
independent processing threads), 10 buffered message channels, and approximately 100 variables. 
The model is constructed in less than a second. 
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Fig. 8 — Servers and Workflow in the TrailBlazer System 
When the user presses the 'check* button on the web browser, a sequence of steps is executed 
to mechanically verify the properties selected Negative results of the verification typically 
flow back to the user within minutes after a check is initiated 
Tbjxep also generates a script that can be used to generate C code for a dedicated verifier for the 
model that was produced, and to compile and nm that code* It now hands hands over the task to a 
central task scheduling server, tbsched by sending it a to the job file. 

2. Tb_sched collects the information and adds it to its table of tasks to be completed. This server also 
collects offers to execute jobs from arbitrary workstations in our network. To make such an offer, the 
workstation runs a small server program called tb_exec. The volunteering workstation can run any 
type of operating system. The FeaVer servers, for instance, run under WindowsNT, and a number 
of dedicated PCs that act as compute-servers run under the Plan9 operating system [P95]. Fifteen 
PCs, shown in Figure 9, are permanently allocated to nm verification jobs. 

3. When the scheduler tb_sched identifies an available workstation it sends the corresponding server 
tb_exec a job script, with information on where any dependent information (e.g., files to be com- 
piled) can be retrieved. Hie scheduler will attempt to have as many task performed in parallel as is 
possible, without overloading any one of the workstations. Typically no new job is assigned to a 
workstation until the previous one has completed. The search itself is performed with an iterative 
search procedure that optimizes our chances of finding errors quickly (side box A). 

4. When a workstation completes a task it signals its renewed availability to the scheduler tb_sched 
and forwards the results of the run to the last server, on the FeaVer system, that performs postpro- 
cessing: tb_wrap. 

5. Tb wrap produces the ASCII and graphical format for error sequences, and generates detailed C 
traces. If no error was found, some statistics on the run are collected, to allow the user to judge the 
validity of the result (see Avoiding false positives). The statistics include the coverage of the prop- 
erty automaton, and the coverage of the model code as a whole. The information is entered in the 
database, and linked to the corresponding properties, so that it becomes accessible to the user via the 
web browser interface. 
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Fig. 9 — TrailBlazer Compute-Servers 
Fifteen standard PCs. running the Plan9 operating system as 
compute servers, give the TraiiBlazer system a performance boost 

Tracking Progress 

When a comprehensive verification cycle is started for ail properties that have been defined, for instance 
after an update of the source text of the application, it is of great interest to know immediately when an 
error sequence for a property has been discovered, so that it may be inspected. Typically this happens 
within the first few minutes of a comprehensive run, but it is of course not known in advance which proper- 
ties might fail. The job scheduler tbsched knows when the processing of an error sequence was com- 
pleted, and can prompt the user, pointing at a URL wbere detailed information on the error sequence can be 
found, through the standard web browser. There is also a visual tracker, written in Tcl/Tk [094], that 
shows the progress of the search with color bars, one for each property being verified. The bar turns red as 
soon as an error sequence has been discovered for the corresponding property. By clicking the bar, the 
detailed information on the sequence can be brought up in a web browser. This application is illustrated in 
Figure 10. 

Separately, another small Tcl/Tk application can be used to track the actions of the scheduler; showing 
visually which machines have volunteered to execute jobs, which have been assigned a job and what the job 
details are, as illustrated in Figure 11. 

Avoiding Falsa Positives 

From the point of view of the verification system, the best possible outcome of a verification attempt is the 
generation of an error sequence. There is a possibility, if the abstraction in the conversion table was chosen 
incorrectly, that the sequence is invalid and consututes, what is called, & false negative. By inspecting the 
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Fig. 10 — Property Verification Tracking 
A list of all properties included in the current verification run is displayed In the figure up to 
eight cycles in the iterative search refinement process are executed The search stops, marking the 
progress line in red as soon as an error is found 
sequence this can usually be determined quickly, and the abstraction can be adjusted to prevent reoccur- 
rences. The absence of errors occurs when the application faithfully satisfies the property, but in this case it 
is possible that the property itself was in fact inadequate. This is called a vacuous property, cf. [KV99], or 
false positive, and it is addressed differently. 
Consider a property of the type we discussed earlier 
a(p->X(0q)) 

It states that whenever a trigger condition p occurs then sometime thereafter, within a finite number of exe- 
cution steps, a response q will follow, where q itself can either be a proper response or a discharge condi- 
tion that voids the need for a response (e.g., an oafaook event that voids the need for a dialtone signal). If 
all is well, there win be executions in which p occurs at least once. If there are no executions possible in 
which p occurs, thai the formula is logically satisfied (note that the condition □ (p q) is satisfied when p 
is invariantly false). But even though the formula is strictly satisfied, it is almost certainly not what the user 
intended. The telltale sign of this false positive can be found in the number of states reached during the 
check for the automaton that corresponds to this property. In the case above, the property automaton never 
leaves its initial state. This occurrence can easily, and mechanically, be detected, so that the user can be 
warned to change the formulation of the property into a more meaningful one. 

Because properties that do not generate error sequences can take the longest run times (i.e., they will pass 
through all iterative passes of the scheduler), the user can ask the scheduler to provide statistics on the runs 
that have been completed for a property. If the first few approximate runs for a property all leave the prop- 
erty automaton in its initial state, strong evidence that the property is void can be available within the first 
few minutes of the verification, and it is not necessary for the user to wait few the complete verification 
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Fig. 11 — System Status Tracking 
Optionally the user of the FeaVer system can track the status of the workstations that have volunteered 
to run verification jobs. A color code identifies which of these workstations are currently free (green), 
which are busy (blue or yellow), which are dead (redh To the left of busy workstations is briefly indicated 
which job they are currently executing: a compilation (yellow) or a verification (bluel 

process to terminate. 
Assessment 

By concentrating on the central portion of the control code for call processing in PathStar, we were able to 
perform unusually thorough checks of critical system properties. This narrow focus, however, also pushed 
some interesting types of properties outside our reach. The main burden on the user of this checking pro- 
cess is the definition of meaningful properties, not on the mechanics of the checking process itself. The use 
of temporal logic can be a stumbling block even for experienced users. To try to remedy this we developed 
the simple timeline editor, that is able to express the majority of the properties of interest in a fairly intu- 
itive way. The vacuity check on apparently positive results from a verification run has also proved to be 
essential: it can be easy to state complex properties that are in retrospect meaningless. We built some 
mechanized checks to warn the user of such occurrences. 

In a production environment, with strict project deadlines, the likelihood that a system error is addressed 
quickly is often inversely proportional to the amount of text that is needed to describe it. Execution 
sequences of thousands of steps that putativeiy violate complex logic properties are not likely to get quick 
attention. We therefore use the verification system in two phases: the first phase is used to identify all pos- 
sible property violations, and the second phase is used to to generate the shortest possible example of each 
violation discovered, selecting the most likely manifestation of the error. This strategy has proven success- 
fui. In most cases an error can be demonstrated in no more than ten to fifteen steps, whereas an initial error 
sequence might contain hundreds and nsk escaping notice. 
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6. Conclusions 

At the time of writing, we have tracked the design, evolution, and maintenance of the PathStar call process- 
ing code over a period of approximately 18 months. In this period, the code grew fivefold in size and went 
through roughly 300 different versions, often changing daily. We intercepted approximately 75 errors in 
the implementation of the feature code by repeated verifications. Many of these errors were considered 
critically important by the programmers, especially in the early phases of the design. About 5 of the errors 
caught were also found independently by the normal system test group, especially in the later phases of the 
project (The traditional testing, of course, addressed the PathStar system as a whole, and did not concen- 
trate solely on the call processing code as we did.) In about 5 other cases the testers discovered an error 
that should have been within the domain of our verifications. These missed errors were caused by unstated 
or ambiguous system requirements; once the proper requirements were added into our database, the viola- 
tions were caught 

Flaws can get enter into source code in the initial design stages, but also, and perhaps more frequently, dur- 
ing routine system maintenance. A portion of routine bug fixes will introduce new bugs into the code. The 
ability of the FeaVer system to repeat comprehensive verification runs immediately after bug fixes are 
made is therefore of great value. New incidences of property violations can be trapped instantly, while the 
rationale for a code change is still fresh in the mind of the developer. 

In several cases we used our verification system in an unexpected way as a diagnostic tool Occasionally 
the testers would run into a problem that could not be reproduced By feeding the event sequence of such a 
test into the FeaVer system the error sequence could be reproduced in these cases and studied to determine 
which race conditions or event timings were responsible for its occurrence, in other cases the programmers 
of the system wanted to confirm their intuition about the occurrence or absence of certain conditions, such 
as a suspected unreachabtlity of part of the code. The verification framework proved ideal to settle such 
question promptly. 

The method of verification we have outlined in this paper should be generally applicable to distributed sys- 
tems code written in most programming languages. Our aim in the coming years is to apply the method to 
a diverse set of applications, so that the checking process can be streamlined and made available for general 
use. 
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Sid* Box A: tterattve SMrch Procedure 

SPIN provides support for performing verification jobs either exactly or with varying degrees of precision, 
using proof approximation techniques. The benefit of an exact run will be clear. An exact verification, 
however, can be time consuming for larger problems. An approximate answer that can be delivered quickly 
is often of more value to a user than a precise answer (hat takes much longer to compute. In an approxi- 
mate verification both the quality and the speed of the run can be controlled with a parameter. As the thor- 
oughness of the run increases or decreases, so do the time requirements. An approximate verification in 
effect performs a random sampling of the behavior of a system, in an effort to find violations of system 
requirements. With this technique we can find a practical compromise between verification and testing. The 
coverage that is achieved in even approximate verification runs is significantly larger than what is achiev- 
able with traditional testing techniques. 

Our experience is that when property violations are possible, even very approximate verification runs can 
identify them. The verification system uses this fact to enforce an iterative search refinement method for 
each verification task. The iterative search procedure starts by allocating the fastest possible, and most 
approximate, runs for each task. The first of these runs typically completes in under a second of CPU time. 
If the run finds an error, the remainder of the runs can be abandoned, and the error sequence can be pro- 
cessed for inclusion in the FeaVer database. If no error is found, the coverage is increased. Hie second run 
may take two seconds, proceeding to four, eight, sixteen second runs, and so on until either an error is 
found or maximal coverage was reached (and with thai proof that no violations of the corresponding prop- 
erty are possible). 

With, say, 200 verification runs to be performed and 20 workstations available to perform the runs, the first 
approximate runs can be completed in about ten seconds for all jobs combined In each new iteration all 
jobs that produced errors are deleted from the workset, and the scan becomes more thorough for the remain- 
ing properties. With this procedure it typically takes a few minutes to identify the first property violation in 
a large set of verification tasks. After about five minutes a representative selection of violations is normally 
available, with the gaps filled in in subsequent searches. The iterative search procedure is abandoned after 
about an hour, whether it has reached fully exact results or not The rationale is that within an hour one 
normally will have looked at the property violations and formulated corrections of the source code. Further 
error sequences would be of little use, since the source code has by now changed, and more value can be 
derived from a new scan of all properties for the new version of the source. 

Once all verification tasks have been completed, an optional second phase of the verification is performed 
by reinspecting every error sequence found and, again iteratively, searching for a shorter equivalent (see 
also Assessment). 

Side Box B: Omega Automata 

The formal definition of an co-automaton, as shown in Figure 4, differs slightly from that of a standard 
finite automaton. Instead of accepting (input) sequences of finite length, like a standard finite automaton, 
an o>- automaton accepts only sequences (in our case representing system executions) of infinite length. 
There are several ways to define the acceptance conditions for an co-automaton [T90]. The definition used 
in SPIN is known as Buchi acceptance. It states that a sequence is accepted if and only if it visits at least 
one accepting state in the automaton (indicated with a double circle in Figure 4) infinitely often. 
The automaton in Figure 4 is also non-deterministic, which makes it's behavior less obvious. In the model 
checking process, the transitions of this automaton are 'matched* one by one against the execution steps of 
the system. Execution starts with the property automaton in its initial state $ 0 * After each step of the system 
the property automaton is forced to make a transition. To do so it can choose only from transitions with a 
label that evaluates to true at this point in the execution. The self-loop on s 0 in Figure 4 can always be tra- 
versed, since if s label necesarily evaluates to true. The transition from $ 0 to s x can only be taken when an 
offhook is detected. Note carefully that i/an offhook is detected the property automaton can either stay in 
j 0 . and ignore this event, or move to s { and start the wait for a dialtone (i.e., it makes a non-deterministic 
choice). The verifier will check the consequences of either choice. The latter is important because we want 
to make sure that every occurrence of an offhook is followed by a dialtone, not just the first occurrence. 
Once the property automaton reaches state s t it can only remain there in the absence of dialtones and 
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onhooks. A sequence is formally accepted by the automaton if and only if it is possible for the property 
automaton to remain in s x forever, infinitely often traversing the self-loop on that state. If a dialtone is 
detected within a finite number of steps, the attempt to match the corresponding execution to the property 
automaton fails, which means that the execution satisfies the original requirement and does not constitute a 
violation. The matching process stops at this point. The model checker will abandon the search of this exe- 
cution and explore other possible executions instead, in a hunt for possible violations. There need not be a 
back-edge from state s { to state s 0 , since all behaviors of interest are already captured by the non- 
determinism on 5 0 (see above). 
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The Working of AX an Automaton extractor from C coda 

Included in this note are three small examples that illustrate the model extraction method from ANSI C 
code with the tool Ax. 
We discuss: 

• A simple implementation of the alternating bit protocol in ANSI C. 

• Two different implementations of a standard quicksort algorithm. The first implementation is the 
version printed verbatim in Kemighan & Pike's book "The Practice of Programming" (Addison- 
Wesley, 1999) on page 33. The second implementation is the same algorithm rewritten as a non- 
recursive procedure. 

Example 1: Alternating bit protocol. 

The source text for this program, written in standard ANSI C, is as follows. The line numbers in the left 
margin were added for easier reference. 

1 # include <stdio.h> 
2 

3 /* 

4 * C version of alternating bit protocol 

5 * to show that the coda need not be 

6 * structured as a stata machine, as 

7 * with the 8 format 

8 * GJH 3/6/2000 

9 */ 

10 typedef char uchar; 
11 

12 typedef struct Buffer { 

13 int size; /* current size of buffer */ 

14 uchar *cont; /* buffer contents */ 

15 } Buffer; 
16 

17 extern int get_data (Buf f er *) ; 

18 extern int put_data (Buf £ er *) ; 
19 

20 int 

21 abp_sender (int N) 

22 { Buffer Bufinp, Buf out; 



23 short s, 3*0, cnt-0; 
24 

25 Buf out. size * 1; 

26 Bufout.cont - n M" ; 

27 while (cnt++ < H) 

28 if ( ! get_data ( 6Buf out) ) 

29 break; 

30 send (fiBuf out, 3) ; 

31 recv(£Bufinp, 6s) ; 

32 if (* Bufinp — 'A 1 ££ s — S) 

33 S - 1 - S; 

34 } 

35 return ant; 

36 } 
37 



38 int 

39 abp^receiver (void) 

40 f Buffer Bufinp, Buf out ; 



41 short s, E*0, cnt»0; 

42 " 

43 Buf out. size * 1; 

44 Bufout.cont » "A"; 

45 while (recv(fcBuf inp, 6s)) 
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46 { cnt++; 

47 send (fcBuf out, s> ; 

48 if (s — E) 

49 { if (»put_data(4Bufinp)) 

50 break ; 

51 E - 1 - E; 

52 ) ) 



53 return ent; 

54 } 

This C program defines the behavior of a sender and of a receiver process. To run the protocol one can 
instantiate two independent processes (asynchronous threads of execution): one process to execute the 
sender's code and one process to execute the receiver's code. Independently of the part of the 
implementation shown here, one then provides two external routines, getjdata () obtains the data to be 
transmitted at the sender side, and putjdata () delivers data to its ultimate destination at the receiver side. 
The details of the code are not of primary interest here, but the process of converting it automatically into 
an abstract model, guided by a user defined conversion (lookup) table. 

Just using this program as input, and without a first version of a lookup table just yet, we can extract a first 
version of a verification model in Promela. The tool 4 ax* will generate a default lookup table for us as well, 
that we can then edit to adjust the abstraction that is applied. 

We extract the two parts of the model separately: a part for the receiver and a part for the sender. The two 
parts are combined in a hand-written wrapper that we place around the code, as shown below. 
The first version of the two parts of die model is generated as follows with the commands: 

$ ax -a abp^rtctivtr abp.c 
$ ax *a abp_sender abp.c 

The two parts of the model are extracted into the files "atop_receiver . spa" and w abp_sender . spn" , 
and the two default lookup tables are written into the files w abp_receiver . lut" and 
"abp sender . lut" . The contents of these two files after this first pass is as follows: 

1. Contents of file abp_receiver . lut : 



# Ax Lookup Table abp_receiver . lut 



D: 


Buffer Buf inp, Buf out; 


hide 


D: 


short a,E»0,cnt*0; 


hide 


A: 


Buf out . sise*l 


hide 


A: 


Buf out . cont" "A" 


hide 


C: 


recvU(Bufinp) ,6(s)) 


true 


C: 


! recv < & (Buf inp) , £ (s) ) 


true 


cnt++ 


print 


P: 


send (£ (Buf ov^; ,s) 


print 


C: 


(s— I) 


true 


C: 


! <s— E) 


true 


C: 


( * put_data(* (Buf inp) ) ) 


true 


C: 


? ( !put data (£ (Buf inp) ) ) 


true 


A: 


E«(1-e7 


hide 


R: 


return 


print 


2. 


Contents of the file abp_ 


sender. lut: 


# Ax Lookup Table abp sender 


.lut 


D: 


Buffer Bufir*p.Bufout; 


hide 


D: 


short s,S»C,cnt«0; 


hide 


A: 


Buf out . size*l 


hide 


A: 


Buf out . cont'K" 


hide 


C: 


<cnt++<N) 


true 


C: 


! (cnt+-KN) 


true 


C: 


( ! get_data (£ (Buf out) ) ) 


true 
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C : ! ( ! get_data ( & (Buf out) ) ) 
F: send (4 (Buf out) ,3) 
F: recvU(Bufinp) ,*<*)> 
C : ( (*Buf inp— ' A< ) && (s««S) ) 
C: ! < (*Bufinp= , A*)«(s— S) ) 
A: S»(l-S) 
R: return 

Ax assigns default mappings to each basic statement that it encounters. Where the context is unambiguous, 
it will classify the statements as either a declaration (prefix "D:")> a condition (prefix "C:"), an assignment 
(prefix "A:"), a function call (prefix "F:"), a return statement (prefix "R:"), The prefix is just optional 
decoration of the lookup table entries. If it cannot be determined from context (as in the case of the 
u cnt++" statements) it is omitted. All prefixes could be omitted without loss of functionality. 
The default mappings used here are "true" for conditions (and their negations), "print" for function calls 
and return statements, "hide" for declarations and assignments. The defaults are just meant as a starting 
point for the definition of a proper abstraction by the user. To do so, we edit these default lookup tables to 
make them reflect more accurately what aspect of the implementation we are interested in and what we 
want to abstract from. Sample revised tables that capture a possible abstraction are as follows. 

Contents of the file abp__rece± ver . lut : 
# Ax Lookup Table abp_receiver . lut 



0: Buffer Buf inp , Buf out ; hide 

D: short s,E»0,cnt»0; byte E, s 

C: recvU(Bufinp) ,6(s)) rq?s 

C: <recv(6(Bufinp) .4(a) ) false 

cnt++ hide 

C: (»— E) keep 

C: !<•— E) keep 

C : ( • put_da ta ( £ (Buf inp) ) ) f el se 

C : ! ( ! put_data ( & (Buf inp) ) ) print 

A: Buf out . size- 1 hide 

A: Bufout.cont^A 1 ' hide 

A: B«(l-E) keep 

F : send ( 6 (Buf out ) , s) sq ? s 

R : return hide 

Contents of the file abp_sender . lut : 

# Ax Lookup Table abp_sender . lut 

D: Buffer Buf inp , Buf out ; hide 

D: short s,S»0,cnt»0; byte s, S 

C: (cnt++<N) true 

C: ! (cnt++<N) false 

C : ( ! ge tjdata ( £ (Buf out) ) ) false 

C : ! ( ! get_data (£ (Buf out) ) ) print 

F: send (MBof out) ,S) rq!S 

C: ((*Bufinp— , A , )M(s—S))s— S 

C: ! <(*Bufinp— ' A f ) M (s—S) ) else 

A : Buf out . size*l hide 

A: Bufout.cont« n M" hide 

A: S-(l-S) keep 

F: recv(6(Bufinp) ,fi(s)) sq?s 

R : ratum hide 



By repeating the two commands from above with the new, now explicitly defined lookup tables, we 
generate the final version of the verification models. 

$ ax -a abp_receiver abp.c 
$ ax -a abp_sender abp.c 



true 

print 

print 

true 

true 

hide 

print 
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This gives the following result. The lookup table files are not modified by Ax in this second pass, since 
they completely cover all basic statements used in the source. In the two displays below we've made some 
cosmetic adjustments to the printed form, e.g., by indenting some comments. The two files are machine 
generated by Ax. 

Contents of file abp_receiver . spn : 

active proctype abp_receiver ( ) 
{ /* 40: D: Buffer Buf inp , Buf out ; */ 

byte E , s; /* 41: D: short s,E»0,cnt«0; */ 

/* 43: A: Bufout . size»l */ 

/* 44: A: Buf out . con t«" A" */ 

LI: 
do 

:: rq?s; /* C: recv (fi (Buf inp) , fi <s) ) */ 
/* cnt++ */ 

sq!s; /* 47: F: send (fi (Bufout) , s) */ 
if 

:: (s— E); 

printf ("C: ! ( !put_dat* (fi (Buf inp) ) ) \n") ; 
E-(l-E); /* line 51 */ 
! (s—B) ; 

fi; 

od; 

/* 53: R: return */ 

> 

Contents of file abp_sender . spn : 

active proctype *bp_sender() 
{ /* 22: D: Buffer Buf inp , Buf out ; */ 

byte s, S; /♦ 23: D: short 8,3-0, cnt-0; */ 

/* 25: A: Buf out . size«l */ 

/* 26: A: Buf out . cont-^M" */ 

L0: 
do 

printf ("C: ! ( !get_d*t*( 6 (Bufout) )) \n") ; 
rq!S; /* 30: P: send (fi (Bufout) ,3) */ 
sq?s; /* 31: F: recv (6 (Buf inp) , fi (s) ) */ 
if 

:: s-»S; /* C: ( (*Buf inp—^' ) ££(s**S) ) */ 

S-(l-S); /* line 33 */ 
:: else; /* C: ! ( (*Buf inp— 'A' ) fifi (s— S) ) */ 

fi; 

od; 

/* 35: R: return */ 

) 

If we edit the source file abp.c, we can reuse the lookup tables from above to re-extract abstract models 
from the modified C code. If new statements were introduced, the model extractor will add default entries 
for them in the lookup table and warn the user about their presence, so that they can be adjusted to conform 
to the abstraction focus that was chosen. If statements were omitted, the model extractor will comment 
them out of the lookup table by placing a comment symbol (#) at the start of these entries. For even 
significant revisions of the source, taking days for the programmer to make, an update of the lookup tables 
to bring them back in sync with the new version of the code typically takes no more than a few minutes of 
user time. (The alternative of rebuilding a complete verification model for the new source by hand would 
more likely take days - approaching the investment of time that the programmer made.) 

We can inspect the behavior of the abstracted implementation with the logic model checker Spin. First we 
join the two parts of the model in a simple Promeia wrapper that defines minimal context for the two 
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processes. The wrapper below defines two abstract channels via which the processes can exchange their 
messages, and includes the text of the two processes. The text of this wrapper, stored in a file called abp, 

is: 

chan rq » [1] of { byta }; 
chan sq * [1] of { byte }; 

#includa "abp^recaiver . spn" 
♦include M abp_sender.spn" 

Now we can run spin on this file. First, we can look at the first 20 steps in a simulation run, looking only at 
message exchanges: 

$ spin -c abp I sad 20q 
proc 0 « abp__raceiver 
proc 1 * abp_sender 

C: !(!get data (6 (Bufout) ) ) 
q\p 0 1 
1 rq!0 

1 rq?0 

2 sq!0 

2 sq?0 
C: ! (!put_data(6(Bufinp))) 

C:~ (!get data (6(Buf out))) 
1 . rq!l " 

1 rq?l 

2 sqM 

2 . sq?l 
C: ! (!put_data(fi(Bufinp))) 

C: ! (?9at w data(6(Bufout))> 
1 rq!0 " 

1 rq?0 

2 sq!0 

C: ! (!put_data(fi(Bufinp))) 

This shows the two processes exchanging the sequence numbers and correctly retrieving and depositing 
data during the run. A verification run can be more illuminating, checking the system for possible 
deadlocks, and answering any other logical query that the user can formulate about the operation of the 
system. 

$ spin -a abp 

$ cc -o pan pan.c 

$ pan 

(Spin Varsion 3.3.10 ~ 6 March 2000) 
+ Partial Order Reduction 

Full statespace saarch for: 

navar-ciai» - (nona spacifiad) 

assartion violations + 
acceptance cycles - (not selected) 

invalid andstates + 

State-vector 36 byte, depth reached 13, errors: 0 
14 states, stored 

2 states , matched 
16 transitions (« stored+matched) 
0 atomic steps 
hash conflicts: 0 (resolved) 
(max size 2 A 18 states) 

1.493 memory usage (Mbyte) 



-30- 



Holzmaim 17 



unreached in proctype abp__receiver 

(0 of 12 states) 
unreached in proctype abp_sender 

(0 of 12 states) 

This verification run proves, for instance, absence of deadlock for the alternating bit protocol. 



Example 2: The Quicksort algorithm. 

The next example serves to show that the model extraction can be applied to arbitrary ANSI C code as 
input, without structuring or style requirements. The code need not be written in a format resembling a 
traditional finite state machine: the model extractor can generate the state machine structure from the 
control flow skeleton of the program for any C program. Model checking for the quicksort algorithm itself 
is not a very fruitful exercise, though, since the algorithm involves no concurrency or process interaction, 
so this is just an example of model extraction, not of model checking. For sequential and deterministic 
algorithms of this type it is generally better to analyze their properties with more conventional techniques. 
Here first is the code from the quicksort algorithm as it appears in a recent textbook (Kernighan & Pike's 
"The Practice of Programming" (Addison- Wesley, 1999), page 33). 

/* swap: interchange v[i] and v[j] */ 

void swap(int v[] , int i, int j) 

< 

int tamp; 

tamp - v[i] ; 
v(i] - v[j]; 
v[j] * temp; 

} 

/* quicksort: sort v[0] . .vCn-1] into increasing order */ 

void quicksort (int v[] , int n) 

{ 

int i, last; 

if (n <» 1) /* nothing to do */ 
return ; 

swap(v, 0, randO % n) ; /* move pivot */ 
last » 0; /* to v[left] */ 

for (i * 1; i < n; i++) /* partition */ 
if <v[i] < v[0]) 

swap(v, ++last, i) ; 

swap(v, 0, last); /* restore pivot */ 
quicksort <v, last); /* recursively sort */ 
quicksort <v+last+l, n-last-1) ; /* each half */ 

> 

We can apply the model extractor to this code, as is, and generate a default lookup table that we can then 
edit as before. The default lookup table that is generated for the quicksort routine looks as follows. 

Contents of quicksort . lut : 

# Ax Lookup Table quicksort . lut 



D: int i,last; hide 

C: (n<-l) true 

C: ! (n<»l) true 

R: return print 

F : swap (v , 0 , (rand ( ) %n) ) print 
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A: last»0 hid* 

A: i*l hid* 

C: (i<n) tru* 

C: ! (i<n) tru « 
C: (v[i]<v[0]) 

C: T(v[i]<vCO]> tru* 

F: swap(v,++last,i) prxnt 

i++ print 

F: swap <v,0, last) print 

F: quicksort (v,last) print 



F: quicksort ( ( <v+last)+l) , ( (n-last) -1) ) print 

Note that the routine is recursive, and in the default lookup table the recursion is mapped away. We can edit 
the lookup table to define the required abstraction, retaining all the functionality from the original program, 
including the recursive calls, but redefined to a smaller domain. 



Contents of r avis ad quicksort . lut: 



4 Ax Lookup Tabla quicksort . lut 
D: int i,last; short i, last, taap; 

C: (i<n) kaap 
C: ! (i<n) k«*p 
i++ kaap 
C: <n<»l) <n-a<-l) 
C: Mn<-1) 

C: <v{i]<v[03> (v(i]<v[aj) 
C: '(vti]<vtO]) 
A: lut»0 last-a 
A: i-1 i-a+1 

F: swap<v,0, <rand()%n)) taap « v[a] ; v[a] » v[(n+a)/2]; vt(n+a)/2J - 

F: swap(v,++last,i) l*st++; t*ap - v[i] ; v(i] - v[last] ; v[lastl - tamp 

F: swap <v,0, last) taap - v[a] ; vfa] - v[lastj ; v[last] - taap 

F: quicksort <v, last) run quicksort (a, last) ; _nr _pr -* _pid+l 

F: quicksort (< (v+last) +1) , { <n- last) -1) ) run quicksort (las t+1, n) ; _nr_j>r — » _pid>l 

R: raturn goto dons 

We repeat the model extraction with the edited table and obtain the following abstract model from the code. 
We extract the model without the proctype enclosure, using the option M -n" instead of the earlier M -a" . 
(Ax has options for generating the models as fully instantiated processes (-a), as uninstantiated process 
declarations (-p) or as process bodies (-n), as used in this case,) 



$ ax -n quicksort qsort.c 
Con tan ts of quicksort . spn : 

short i, last, tanp; /♦ 18: D: int i,last; */ 

if 

:: <n-a<«l>; /*C: <n<«l) */ 

goto dona; /* 21: R: raturn */ 
: : alsa; /* C: ! (n<-l) */ 

fi; 

tamp » v[a]; v[a] « v[(n+a)/2]; v[(n+a)/2] » tamp; 

/* 23: F: swap <v, 0, (rand () %n) ) */ 
last-a; /* 24: A: laat-0 */ 
i«a+l; /* 25: A: i»l */ 

LO: 
do 

: : (i<n) ; 
if 

:: (v[i]<vta3); /* C: (v[i]<v[03) */ 

last++; tamp - v[i] ; v[i] - v[last] ; v[laat] - tamp; 
/* 27: F: swap <v, ++last, i) */ 
:: alsa; /* C: !<v[i]<v[0]) */ 

fi; 
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! (i<n) ; -> braak 

od; 

tmaxp - v[a]; v[a] » v[laatj ; v[last] - twmp; /* 29: F: swap (v, 0, last) */ 
run quicksort (a, last) ; _nrj>r — _J>id+l; /* 30: F: quicksort <v, last) */ 
run quicksort <last+l, n) ; _ft*J>* ™ _pid+l; 
/* 31: F: quicksort (( (v+last) +1) , < (n-last) -1) ) */ 
goto dona; /* 31: R: raturn */ 

We now have to define the wrapper that defines the context for the generated model. In the wrapper we can 
pass some data to be sorted to the quicksort process, and check that it was sorted correctly after that process 
completes. For the example we'll use the following wrapper for the quicksort model: 

Contants of f ila *quick' : 

short v[16J ; 

inlina chackrasult () { 
d stap { 

i~« 0; 
do 

: : i < n-1 -> 

assart(vEi] <-v[i+l]>; 
i++ 

: alsa -> 

braak 

od; 
skip 

} 



proctypa quicksort (short a, n) 
{ atonic { 

print* ( "quicksort %d - %d\n w , a, n) ; 
iincluda "quicksort. spn" 
dona : skip 

} 

} 

init { 

short i, n; 
if 

: : n » 6 /* avan valua for n */ 

: n » 5 /* odd valua for n */ 

: n » 0 /* boundary casa */ 

: n » 1 /* boundary casa */ 

fi; 
do 

: : i < n -> i++ ; 
if 

: : v{i] - 15 
:: v[i] - 9 
:: v[i] - 4 
: : v[i] - 27 
:: v[i] - 11 
fi; 

: alsa -> 
braak 

od; 

run quicksort (0,n) ; 
_rir_pr M jpid+1; 
chackrasult () 

} 
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We seed the model with some random input date. We chose between 0 and 6 numbers, arbitrarily from the 
set 4, 9, 1 1, ! 5, and 27 and put them in random order (using non-deterministic choices that are native to the 
modeling language Promela). Then we call the quicksort routine over the range of numbers selected. The 
line" nrjpr — j>id+l" in Promela guarantees that the last procedure call (really a process 
instantiation) completes before we continue. The final call to "checkrasult () " will verify that the 
numbers were correctly placed in numerical order, whatever their initial order may have been. 

Example 3: A Non-Recursive Version of Quicksort: 

Although the model extraction is straightforward for the recursive version of the quicksort algorithm, the 
definition of the lookup table requires some thought. It can be much simpler if the original C code is closer 
in nature to the target modeling language (in this case Promela). As an example of this, below is a revised 
version of the quicksort algorithm, functionally equivalent to the original, not relying on recursion. 

Revised qsort.c: 

♦include <stdio.h> 
#include <stdlib.h> 

♦define Max! 100000 
♦def ine MaxD 64 

int debug » 0; 

void 

assert (int e) 
{ 

if <!e) 

{ printf ("stack overf low\n") ; 

exit(l) ; 

} 

} 

♦define swap(i,j) temp » v[i] ; v[i] - v[j]; v[j] « temp 
♦define putQ(x,y) assert(Qsx < MaxD); from[Qin] » x; \ 

uptoCQin] • y; Qin - (Qin+1) %MaxD; Qsx++ 
♦define getQO * - fromCQout] ; b » upto[Qout] ; Qout « (Qout+1) %MaxD; Qsz-- 

void 

main (void) 

( int i, n, j, k, last, temp; 

int v[MaxI], from [MaxD ] , upto[MaxD]; 
int Qin«0, Qout«0, Qss«0, a, b; 

for (n ■ 0; n < Maxl; n++) 

if (fscanf (stdin, "%d w , 6v[n]) — IOff) 
break; 

if (n «■ 0) goto dona; 

putQ<0, n-1); 
while (Qss > 0) 
( getQO; 

if (b-a <» 0) 

continue ; 
k ■ a+rand<)%(b-a) ; 
swap (a, k) ; 
last « a; 

for (i - a+1; i <- b; i++) 
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if (v[i] < v[a]) 
{ last++; 

swap (last, i) 

> 



swap (a, last) ; 
putQ(a, last) ; 
putQ<last+l, b) ; 



dona: 

for (j * 0; j < n; j++) 

printf <"%d\n rt , v[j]) ; 
axit<0) ; 

} 

The version shown above is a complete self-contained program, that reads in numbers from the standard 
input, sorts them with the quicksort algorithm, and then prints out the result on standard output. 
The lookup table for the main routine can now be defined as follows, consisting mostly of "kaap" 
mappings that are preserve the text from the source verbatim in the target: 

Contants of main.lut: 

# Ax Lookup Tabla main.lut 

# map into smaller domain: 

D: int v[100000] ,from[64] ,upto[64] ; int v[8] , from [8] , upto[8] 

F: assart ( (Qsz<64>) assart ( <Qsx<8> ) 

C: (n<100000) (n<8) 

C: ! <n<100000) » (n<8> 

A: k«(a+{rand()%<b-a))) k«((a+b)/2) /* datarminixa */ 

A: Qout»(<Qout+l>%64) Qout- < <Qout+l) %8) 

A: Qin»((Qin+l)%64) Qin-< (Qin+l) %8> 

# litaral, with syntactic conversion: 

D: int i , n, j , k, last , tamp; int j ,k, last, temp; 

F: axit(0) hida 

R: r a turn chackrasult () 

C: (fscanf <6( dj_stdin) , "%d M , 6 <v[nj ) ) — (-1) ) ampty(qin) 

C: ! (fscanfU <_dj"_stdin) , n %d», £ <v[n] )) — (-!)) qin?k; v[n] « k 
q»x++ Qsx++; assert <Qsx<«n+l) 

q»x — Q»* — '» assert <Qsx>«0) 

# tha rast is litaral: 

D: int Qin-0 ,Qout«0 ,Qss«0 , a,b; kaap 
F: printf <"%d\n" ,v[ j] ) kaap 



(QszX)) kaap 

! (Qsz>0) kaap 

<(b-a)<«0) kaap 
!((b-a)<«0) 

(i<»b) kaap 

! (i<-b) kaap 

<v[ij<v[a]) kaap 

!(v[i]<v[a]) kaap 

<j<n) kaap 
! ( j<n) 
(n— 0) 

! (n— 0) kaap 
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A: n»0 


ItMp 


A: from [Qin] »0 


kMp 


A: upto[Qin)»(n-l) 


JC**P 


A: a»f romCQout] 


ka«p 


A: b*upto[Qout3 


kMp 


A: tamp»v[aj 


kMp 


A: v[a]«v[k] 


kMp 


A: v[k]*tamp 


kMp 


A: last-a 


kMp 


A: i«(a+l) 


kMp 


A: tamp*v[la»t3 


kMp 


A: v[la«t]«v[i] 


kMp 


A: v[i3»tamp 


kMp 


A: v[a3~v[la»t3 


kMp 


A: v[ last] -tamp 


kMp 


A: from [Qin] *a 


kMp 


A: upto[Qin]*last 


kMp 


A: from[Qin]*(laat+l) 


kMp 


A: upto[Qin]»b 


kMp 


A: j«0 


kMp 


i++ 


kMp 


n++ 


kMp 


j++ 


kMp 


laat++ 


kMp 



The lookup tabic is used here mostly to restrict the maximum range of numbers and to convert the style of 
reading input and writing output Finally, the wrapper for the extracted model in this context can be 
defined as follows: 



chan qin * [6] of { int }; 

inline chackraault () { 

i ■ 0; 
do 

: : i < n-1 -> 

a«sart<v[i3 <» v[i+13>; 
i++ 

: alsa -> 

braak 

od 

> 



init { 

byta i, n; 

if 

: n * 6 /* avan valua for n */ 

: : n * 5 /* odd valua for n */ 

: n - 0 /* boundary caaa */ 

: n » 1 /* boundary caaa */ 

fi; 
do 

: : i < n -> i++; /* placad togathar to gat a marga pair */ 
if 

:: qin! 15 /* choosa from n diffarant or aqual nra */ 

:: qin! 9 /* wa could alao fill in tha v[]'s diractly */ 

: qin! 4 
:: qin! 27 
: : qin! 11 
fi; 

: alsa -> 
braak 

od; 
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skip; /* syntax requirement */ 
d_atep { 
iinclude" "main . spn" 

) 

) 

As noted, the objective of this exercise is not to verify the quicksort algorithm, but to demonstrate that 
model extraction from arbitrary ANSI C code is possible with the Ax model extraction tool 
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